Due to security concerns and/or scarcity of Internet protocol version 4, IPv4, addresses, network address port translation, NAPT and stateful firewalls are frequently deployed on IP networks, limiting peer-to-peer connectivity. Still, in many cases UDP packets (UDP, user datagram protocol as described in RFC768) can be exchanged between NATed/firewalled nodes, using an out-of-band signaling mechanism (e.g. session initiation protocol, SIP) and e.g. a “hole punching” mechanism such as ICE, interactive connection establishment as described in IETF draft-ietf-mmusic-ice. IETF stands for Internet Engineering Task Force, address http://www.ietforg. ICE makes use of the session traversal utilities for network address translation, STUN, protocol and its extension, and traversal using relay network address translation, TURN. ICE can be used by any protocol utilizing the offer/answer model, such as the session initiation protocol, SIP.
UDP does not provide any kind of reliability or congestion control, making it only suitable e.g. for loss-tolerant real-time data (e.g. voice).
For reliable and fast transfers, the transport control protocol, TCP as described in IETF RFC793, may be used. A stream control transmission protocol, SCTP, of RFC2960 or other protocols may also be used.
Peer-to-peer TCP (using TCP Simultaneous Open) as specified in ICE-TCP does not work through as many network address translations, NATs/firewalls as peer-to-peer UDP.
ICE-TCP (IETF draft-ietf-mmusic-ice-tcp) proposes the use of TCP Simultaneous Open, whereby the two ends send normal TCP connection requests to each other at the same time. However, different NATs models e.g. from different vendors do not allow TCP Simultaneous Open.